home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: seebs@solutions.solon.com (Peter Seebach)
- Newsgroups: comp.lang.c
- Subject: Re: Is this a C BUG??? (A string issue)
- Date: 2 Apr 1996 06:55:46 -0600
- Organization: Usenet Fact Police (Undercover)
- Message-ID: <4jr84i$hea@solutions.solon.com>
- References: <4jknpf$9k3@abel.cc.sunysb.edu> <AD84A72A96681716E4@mcdiala03.it.luc.edu> <4jp9s4INNpp2@keats.ugrad.cs.ubc.ca> <AD86126F966859743@mcdiala13.it.luc.edu>
- NNTP-Posting-Host: solutions.solon.com
-
- In article <AD86126F966859743@mcdiala13.it.luc.edu>,
- Verne Arase <VArase@varase.it.luc.edu> wrote:
- >The standard I/O f<...> functions are fine for formatted I/O, and I/O where
- >compatible stream functions are desired, but aren't that great for fixed
- >length record I/O.
-
- >read/write allow you to slam in or out a specified number of bytes
- >into/from a buffer; how is that restricting I/O to a single record at a
- >crack?
-
- He said "a naive implementation".
-
- fread/fwrite allow you to do just the same thing. I have generally found
- that, unless the blocks I'm reading are multiples or divisors of disk block
- size (mostly multiples), read/write are painfully slow by comparison. Why?
- Because they involve system call overhead every time I use them. fread and
- fwrite frequently work with a non-trivial buffer somewhere in stdio, and
- are able to:
- 1. Minimize calls to the system.
- 2. Make sure all reads and writes are properly aligned buffers of a good
- block size.
-
- Obviously, any description of how read/write are different is atopical.
-
- -s
- --
- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
- C/Unix wizard -- C/Unix questions? Send mail for help. No, really!
- FUCK the communications decency act. Goddamned government. [literally.]
- The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
-